A generic framing procedure (GFP) is used to encapsulate octet-aligned, variable-length payloads from higher-level client signals for subsequent mapping into octet-synchronous payload envelopes. An example of the GFP is described in ITU-T G.7041 standard.
A block diagram of a GFP frame 100 as specified in the ITU-T G.7041 standard is shown in FIG. 1. The GFP frame 100 includes a Core Header 102 that has a length of four octets, and a variable length payload area 104 that may include four (4) to sixty-five thousand five hundred and thirty five (65 535) octets. The Core Header 102 includes a two octet (16-bit) payload length indicator (PLI) field 106, and a two octet Core Header Error Control (cHEC) field 108 that contains a cyclic-redundancy-check (CRC-16). The variable length payload area 104 includes a payload header 110 that has a variable length of four (4) to sixty-four (64) octets, a client payload information field 112, and an optional payload frame check sequence (FCS) 114.
The payload header 110 includes a four octet Type Header 116 and a variable number of additional payload header fields, referred to as a group as the optional Extension Header 118. The optional Extension Header 118 may include zero (0) to sixty (60) octets. The Type Header 116 includes a two octet Type Header field and a two octet Type Header Error Control field. The two octet Type Header field includes a three-bit Payload Type Identifier (PTI) 120, a one-bit Payload FCS Indicator (PFI) 122, a four-bit Extension Header Identifier (EXI) 124, and an eight-bit User Payload Identifier (UPI) 126. The two-octet Type Header Error Control field includes a CRC-16 generated sequence 128 that protects the integrity of the contents of the Type Header field by enabling both single-bit error correction and multi-bit error detection, as outlined in the ITU-T G.7041 standard, which is incorporated herein by reference.
Referring to FIG. 2, a block diagram of a state machine 200 for a GFP frame delineation method in accordance with the ITU-T G.7041 standard prior to August 2012 (hereinafter referred to as “the original GFP frame delineation method”) is shown. The original GFP frame delineation method is performed in relation to the state diagram of FIG. 2 and is based on the correlation between the first two octets of the GFP frame 100 and the embedded two-octet cHEC field 108. The state diagram of FIG. 2 works in the following manner.
In the HUNT state 202, the original GFP frame delineation method performs a frame alignment search by searching, octet by octet, for a Core Header 102 over the last received sequence of four octets. Core Header correction is disabled while in this state. During the HUNT state 202, a group of four octets is considered to be a candidate Core Header 102 when, after Barker decoding, the value in the last two octets of the group represents a correct CRC-16 over the value in the first two octets of the group. At this point a candidate Core Header 102 of a candidate GFP frame is identified and the method enters the PRESYNC state 204.
In the PRESYNC state 204, the original GFP method performs frame delineation by checking for a correct cHEC match in the Core Header 102 of the next candidate GFP frame 100. The PLI field 106 in the Core Header 102 of the preceding GFP frame 100 (i.e. the candidate GFP frame identified in the HUNT state 202) is used to locate the beginning of the next candidate GFP frame 100. Core Header correction is disabled while in the PRESYNC state 204. The method repeats until a predetermined number (DELTA) of consecutive correct cHECs are confirmed, at which point the method enters the SYNC state 206. If one incorrect cHEC is detected, the method returns to the HUNT state 202. The total number of consecutive correct cHECs required to move from the HUNT state 202 to the SYNC state 206 is therefore DELTA+1.
It is noted that robustness against false delineation in the original frame delineation method depends on the value of the parameter, DELTA. DELTA is selected to make the original GFP frame delineation method robust, with reasonable hardware complexity. For example, a value of DELTA=1 is suggested to achieve sufficient robustness, with reasonable hardware complexity.
In the SYNC state 206, the original GFP method performs frame delineation by checking for a correct cHEC match on the next candidate GFP frame 100. The PLI field in the Core Header 102 of the preceding GFP frame is used to find the beginning of the next candidate GFP frame 100. Single-bit Core Header correction is enabled while in this state. Frame delineation is lost whenever multiple bit errors are detected in the Core Header 102 by the cHEC. In this case, a GFP Loss of Synchronization event is declared and the method returns to the HUNT state 202.
The GFP frame recovery state machine 200 for the original GFP frame delineation method described above and shown in FIG. 2 relies exclusively on GFP Core Headers 102 to delineate GFP frames from a serial data stream comprising GFP frames. Specifically, once a candidate Core Header 102 is found (i.e. a four-octet pattern with the last two octets representing a valid CRC-16 over the first two octets), the first two octets are regarded as a candidate Payload Length Indicator (PLI) 106. If this candidate Core Header 102 is an actual Core Header 102, the Core Header 102 for the next GFP frame 100 will appear immediately after the end of the current GFP frame 100, as indicated by the candidate PLI 106. The original GFP frame delineation method must therefore wait until this next location of a GFP Core Header 102 to determine whether the current candidate Core Header 102 may be regarded as an actual Core Header 102.
While the original GFP frame delineation method shown represented by the state diagram of FIG. 2 may be repeated through a chain of candidate Core Headers 102 for additional robustness, the ITU-T G.7041 standard recommends that a single candidate Core Header 102 that correctly points to a second candidate Core Header 102 is sufficient to enter the SYNC state 206. The M virtual framers 208 shown in the state diagram 200 of FIG. 2 may be used to test for other candidate Core Headers 102 in parallel while waiting to see if the candidate PLI 106 points to a correct Core Header 102.
A reason for relying on the Core Header 102 to delineate GFP frames from a serial data stream comprising GFP frames in the original GFP frame delineation method is that only the Core Header 102 contains bits that are not scrambled with a self-synchronous scrambler that covers the GFP frame payload area 104. A Barker-type code covers the Core Header 102; however, that is a simple exclusive-or (XOR) with a fixed constant pattern that may be removed by a GFP receiver before computing the validity of the CRC-16.
Referring again to FIG. 1, the Type Header 116 has the same length as the Core Header 102, and the Type Header 116 is covered by a CRC-16 that uses the same polynomial as the Core Header 102. If the Type header 116 was not scrambled, the Type Header 116 may be utilized for faster GFP frame delineation, which could potentially eliminate or simplify the PLI-tracking portion of the original GFP frame delineation method. Unfortunately, the Type Header 116 is covered by an X43+1 self-synchronous scrambler, which makes each of its bit values dependent on the values of the last GFP data/control/management frame. As such, the X43+1 GFP payload descrambler 300 shown in FIG. 3 and described in the ITU-T G.7041 standard is not able to provide any of the information required to descramble the Type Header 116 during a frame alignment search (i.e. the HUNT state 202).
Improvements in frame delineation methods for a GFP are therefore desirable.